OpenEdge Getting Started:<br />OpenEdge Reference Architecture Internal views of data

Data Access Objects allow you to define an internal schema or view of data that differs from the way that the data is actually stored. The purpose is to tailor the representation of data to better suit the needs of a particular application.

In many cases, because of the evolution of a database design over time, the reuse of databases inherited from older applications, and other factors, your current database schema might not be an ideal way for your business logic to refer to and manage your data. An older database might have shortcomings that you want to mask in newly architected business objects and business logic. For example:

The database might not be properly normalized, so that you must execute complex queries to relate data in one table to another. There might also be redundant data that requires fields in multiple tables to be updated when data in one table changes.

The database might have inconsistent naming conventions, or similar data might be stored in different places in different ways. This could result in a single entity, such as a customer number, being stored in different tables under different names, in different formats, or even in different data types. Internal representation should be consistent.

The database might contain overly large tables with many fields that have accumulated over time. For example, various special end-user features might require more and more fields to hold values used by only a subset of your users. Often these fields could be logically grouped according to when or by whom they are needed, so that internal tables do not use or see all the fields simultaneously.

Conversely, sometimes multiple tables that really represent a single data entity must be joined together because they were developed at different times. Internally, these might better be seen as fields in a single table.

Often, you want to denormalize the data internally but not in the database. For example, it might be helpful to include the customer name along with customer number internally, if they must be viewed together. However, you would not want to repeat the customer name in other tables that use the customer number as a key.

These are just a few of the considerations that would lead you to want to provide a different internal view of data from how it is actually stored. Even when the database is well designed, sometimes you might want the internal view of the data to be different. For example, you might want to present a denormalized view, or a specially filtered subset of the data to the application.

If you have an existing application, it is likely that you cannot perform an extensive cleanup of the database schema as an initial part of a transformation effort. For example, it might not be feasible to convert databases to a new form all at once when you have a large installed user base. Also, you might have legacy reports and business logic procedures that you expect to reuse or repackage in the newer version of your application. If you make extensive changes to the database schema, you might improve the quality of the data representation at the expense of much more upfront design and development work, along with more disruption to your current installed base.

Isolating the database schema specifics in the Data Access Layer of your modernized procedures lets you clean up or otherwise change the underlying schema independent of how the application logic uses the data. When you make changes to the schema, only the mapping code in the Data Access Objects needs to change. If you have older procedures that reference the database directly, then these can be kept isolated from the new internal definitions until you are prepared to rework or replace them.